Payments
The Payments module enables you to control how payment requests to external payment platforms are handled. This includes Mandate Revision Control, Recurring Payments Rejection Control, Payment Term Defaults, and Payment Terms.
You can configure mandate revision codes that are supplied in the mandate file from the bank and control whether an inbound file triggers mandate cancellation or amendment.
When customers choose to pay by direct debit, CMP
Converged Monetisation Platform. The MDS Global product that supports customer care and billing for digital service providers. users configure direct debit instructions to send to the customer
In the context of the Cloud Monetisation Platform, an individual or organisation who has signed an agreement to take goods and services from a service provider. A customer receives a bill associated with one or more subscriptions, and can be a single end user or a large company with many subscriptions assigned to one agreement.'s bank, which are known as mandates.
New, amended or cancelled direct debit instructions are extracted daily from CMP in the Automated Direct Debit Instruction Service (AUDDIS
Automated Direct Debit Instruction Service. A service that allows you to send Direct Debit Instructions to a customer's bank electronically.) extract. The AUDDIS extract is sent to a third party
Of software; a reusable component developed to be either freely distributed or sold by an entity other than the original vendor of the development platform. payment handler to be transmitted to Bankers Automated Clearing Service (BACS
Bankers Automated Clearing Services. A system in the United Kingdom for making payments directly from one bank account into another.) for processing.
If no response is received from BACS, the direct debit instruction is successful.
If a direct debit instruction is unsuccessful, details of the failure including a mandate revision code are returned from BACS, via the third party payment handler, in the Automated Direct Debit Amendment and Cancellation Service (ADDACS
Automated Direct Debit Amendment and Cancellation Service. An electronic messaging service that allows banks to notify service users if changes are made to a customer's Direct Debit Instruction (DDI), for example a cancellation or an account transfer.) extract.
CMP processes ADDACS files, taking the appropriate configurable action against the account
In the Cloud Monetisation Platform, a billing entity that can be used to manage payments on one or more subscriptions or payments for services. An account can hold details such as payments or invoices., which can include:
- Cancelling the direct debit.
- Requesting that direct debit details are changed and resubmitted.
The Payments module allows you to configure the mandate revision codes that the banks supply in the ADDACS extract. To do this, you:
- Provide a unique alphanumeric code for the mandate revision code.
- Supply a brief descriptive name for the mandate revision code.
- Specify whether the action to take will be to amend or cancel the direct debit instructions (the mandate).
- Provide a reason for the workflow event that will handle the mandate revision by selecting a reason type and reason code.
- Configure the workflow event to raise to handle the mandate revision by specifying an event type and event code.
You can define recurring payment rejection codes to be supplied in the recurring payment file from the bank for both rejected recurring card payments and direct debit payments to control how the rejection is handled.
When recurring payment and refund transactions are sent to an external payments system, some transactions can fail, for example due to insufficient funds or lost and stolen cards. These rejected transactions must be processed by CMP.
The Recurring Payments Rejections job can be run for direct debit and recurring card payments. It generates a batch that contains records to reverse each failed transaction from the sales ledger. Once this batch has been created, it is detected by dedicated daemons, which format the batch and transmit it to the target sales ledger. This job also generates workflows, for example, to send a communication to the customer, processes soft declines to temporarily exclude the account from the automated payments process and processes hard declines to revert the account to the default (manual) payment to make alternative arrangements for collection of amounts due.
How the job handles the payment rejections are specified by recurring payment rejection codes, which the banks include in the rejected payment extracts that are sent to CMP. You configure these code in the Payments module.
Each recurring payment rejection code must include:
- A unique alphanumeric code.
- A brief meaningful description.
- The reason code and reason type.
Further configuration depends on whether the rejection is a soft decline or a hard decline:
Soft Declines are a result of a temporary error. Payments with soft declines can be retried a specific number of times by including the failed payment on a future recurring payments extract. The number of retries and a specific reason code is configurable. The retries have an associated workflow event and the appropriate actions are automatically completed. You can also configure the number of days that the account is suspended from the automated payments process. Once the maximum number of retries is reached, recurring payment is cancelled and treated as a hard decline. A workflow event is configurable for this because the recurring payment will be cancelled.
Hard declines are permanent errors and the recurring payment is not retried. A hard decline results in CMP automatically changing the customer’s Payment Type to the configured default and the payment is reversed in the CMP Ledger, for which a refund workflow event can be configured in the recurring payment rejection code.
Payment terms are the rules that define how, when, and by what method a customer is expected to pay for goods or services. They outline the conditions agreed upon between a seller and buyer regarding invoice payments, including due dates, payment methods, and any potential penalties for late payments. In CMP, payment terms represent the terms of payment agreed to by the customer, for example, within 14 days of invoice date.
To create a payment term, you need:
-
A unique alphanumeric code (all uppercase) for the payment term of up to three characters.
-
A brief meaningful description of the payment term of up to thirty characters.
-
The number of days in which the customer has to settle their invoice.
Payment term defaults refer to the automatically applied conditions that define when a payment is due for an invoice. In CMP, payment term defaults allow you to define a payment term with a selected payment type to be used as the default when creating accounts.
To create a payment term default, you need:
-
A unique alphanumeric code (all uppercase) for the payment term default of up to three characters.
-
The payment type to be the assigned to the default payment term.
-
The security levels that have access to the payment term default.